Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-074.TXT

Text File | 1992-06-04 | 45.5 KB | 1,245 lines

C.S.M.P. Digest             Fri, 08 May 92       Volume 1 : Issue 74

Today's Topics:

    CDEF values while tracking
    Trouble initializing structures in THINK C 5.0.2
    SADE en MPW
    Where are HD icons stored?
    fortran object files
    How to copy resource file?
    Hard drive icons?
    Very Early Macintosh Systre
    GWorld Woes
    Looking for C++ Compiler for Mac
    Macintosh C Programming primer examples (Q) Where?
    Problem with THINK C 5.0.2 (long)


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail]
Subject: CDEF values while tracking
Date: 28 Mar 92 05:58:28 GMT
Organization: The University of Melbourne

I have recently been messing around with some CDEFs to create a sliding lever
not unlike the one that can be found in the sound control panel. Next to the
sliding lever is an edit field which displays the value of the CDEF. However,
the value is only updated when TrackControl (called via ModalDIalog) senses
that the user has released the mouse button. This is of not much use.
Application such as SuperPaint (trade mark blah, blah, blah...) manage to
update the edit field while the user is moving the control. How do they do it?
I would be eternally grateful to anyone who could give me some examples and
maybe an explanation to go with it.

Thanks in advance :-)

+++++++++++++++++++++++++++

From: [e-mail] (Tommy Nordgren)
Date: 6 Apr 92 15:23:36 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]>, [e-mail] writes:
|> I have recently been messing around with some CDEFs to create a sliding lever
|> not unlike the one that can be found in the sound control panel. Next to the
|> sliding lever is an edit field which displays the value of the CDEF. However,
|> the value is only updated when TrackControl (called via ModalDIalog) senses
|> that the user has released the mouse button. This is of not much use.
|> Application such as SuperPaint (trade mark blah, blah, blah...) manage to
|> update the edit field while the user is moving the control. How do they do it?
|> I would be eternally grateful to anyone who could give me some examples and
|> maybe an explanation to go with it.
|>
|> Thanks in advance :-)
You must:
1. Use a dialog filter function.
2. When the filter function detects a mouse click in the control, track the
   control yourself, using a custom tracking procedure.
3. Some notes. The port is NOT automatically set up when your filter function is
called. FindDItem returns a Zero-based number. Other dialog manager routines
expect a One-based number as argument.

+++++++++++++++++++++++++++

From: [e-mail] (Tommy Nordgren)
Date: 6 Apr 92 15:23:36 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]>, [e-mail] writes:
|> I have recently been messing around with some CDEFs to create a sliding lever
|> not unlike the one that can be found in the sound control panel. Next to the
|> sliding lever is an edit field which displays the value of the CDEF. However,
|> the value is only updated when TrackControl (called via ModalDIalog) senses
|> that the user has released the mouse button. This is of not much use.
|> Application such as SuperPaint (trade mark blah, blah, blah...) manage to
|> update the edit field while the user is moving the control. How do they do it?
|> I would be eternally grateful to anyone who could give me some examples and
|> maybe an explanation to go with it.
|>
|> Thanks in advance :-)
You must:
1. Use a dialog filter function.
2. When the filter function detects a mouse click in the control, track the
   control yourself, using a custom tracking procedure.
3. Some notes. The port is NOT automatically set up when your filter function is
called. FindDItem returns a Zero-based number. Other dialog manager routines
expect a One-based number as argument.

---------------------------

From: [e-mail] (Jerry Frain)
Subject: Trouble initializing structures in THINK C 5.0.2
Date: 30 Mar 1992 02:58:55 GMT
Organization: Kansas State University, Dept. of Computing and Information Sciences


My apologies if this has been thrashed before, and I missed it.

Can anyone tell me why the following is correct

    struct foo {
        int a;
        int b;
    };
    struct foo bar[2] = {{1, 2}, {3, 4}};

And yet this is not:

    struct foo {
        char *a;
        char *b;
    };
    struct foo bar[2] = {{"1", "2"}, {"3", "4"}};

I get "illegal initialization" when compiling the above.  Did I miss
something in the documentation about THINK C 5.0.2 not being able to
do aggregate initialization of strings?

BTW, the initialization was *not* attempted in the body of a function
(if that was your first guess).

The above structure initialization compiled (and ran) fine using Sun
cc and gcc.

  --Jerry Frain, [e-mail]



+++++++++++++++++++++++++++

From: [e-mail] (Jerry Frain)
Date: 30 Mar 92 06:58:41 GMT
Organization: Kansas State University

[e-mail] (Jerry Frain) writes:
>     struct foo {
>         char *a;
>         char *b;
>     };
>     struct foo bar[2] = {{"1", "2"}, {"3", "4"}};

> I get "illegal initialization" when compiling the above.  Did I miss
> something in the documentation about THINK C 5.0.2 not being able to
> do aggregate initialization of strings?

Turns out that the above code only works if the project type is an
application, I was making a code resource.

  --Jerry Frain, [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 30 Mar 92 23:07:38 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jerry Frain) writes:
>
> [e-mail] (Jerry Frain) writes:
> >     struct foo {
> >         char *a;
> >         char *b;
> >     };
> >     struct foo bar[2] = {{"1", "2"}, {"3", "4"}};
>
> > I get "illegal initialization" when compiling the above.  Did I miss
> > something in the documentation about THINK C 5.0.2 not being able to
> > do aggregate initialization of strings?
>
> Turns out that the above code only works if the project type is an
> application, I was making a code resource.

That's right. The reason for this is because you are trying to
initialize the array with pointers to strings. These pointers
take the form of absolute memory locations. There is no way to
determine these absolute memory locations at compile time. Applications
take care of patching up the pointers when they are launched through
some runtime support routines (in MPW, the routine is __DATAINIT. Under
THINK, I think it's through the DATA resource, but that's just a wild
guess). There are no such runtime support routines for standalone
code, and, even if there were, they'd have to take into account the
fact that standalone code resources can be unlocked and moved around
in memory, invalidating the string pointers.

+++++++++++++++++++++++++++

From: Steve Creps <[e-mail]>
Organization: Indiana University
Date: Mon, 6 Apr 1992 10:01:10 -0500

In article <[e-mail]> [e-mail] (Jerry Frain) writes:
>Can anyone tell me why the following is correct
>
>    struct foo {
>        int a;
>        int b;
>    };
>    struct foo bar[2] = {{1, 2}, {3, 4}};
>
>And yet this is not:
>
>    struct foo {
>        char *a;
>        char *b;
>    };
>    struct foo bar[2] = {{"1", "2"}, {"3", "4"}};

   I've not used Think C.  However, this is not specifically a Mac programming
problem, but rather a general C programming problem.

   In Example 1 all the memory locations get allocated because there are no
pointers used (unless you want to get technical).  Both fields in struct foo
are int, so when you declare a variable as struct foo, the memory locations
to hold both a and b are allocated.

   In Example 2, however, you are declaring the fields of foo as _pointers_,
so all that gets allocated are places to hold addresses of places to hold
characters.  Note that "char *a" doesn't tell how big the string is.
Declaring it "char a[2]" would work, because that would actually allocate
two characters for the given string (including the zero terminator).

   Note the following similar examples:

Example 3:

int foo = 1;

Example 4:

char *foo = "1";

   Both of these, however, should work.  Example 4 works not because space is
being allocated for the string, but because it is getting the address of the
space _which has already been allocated_ to store the constant string "1".

   To summarize, the problem mentioned was caused by not making sure that
space was being allocated for strings being used.  That problem is one of
the most difficult concepts to master when learning C.

- -    -    -    -    -    -    -    -    -    -
Steve Creps, Indiana University
[e-mail] (129.79.1.6)
{inuxc,rutgers,uunet!uiucdcs,pur-ee}!iuvax!silver!creps

+++++++++++++++++++++++++++

From: [e-mail] (Brian Donnell)
Date: 6 Apr 92 20:56:41 GMT
Organization: NASA/JSC

In article <[e-mail]>, Steve Creps <[e-mail]> writes:
> In article <[e-mail]> [e-mail] (Jerry Frain) writes:
> >    struct foo {
> >        char *a;
> >        char *b;
> >    };
> >    struct foo bar[2] = {{"1", "2"}, {"3", "4"}};
>
>    In Example 2, however, you are declaring the fields of foo as _pointers_,
> so all that gets allocated are places to hold addresses of places to hold
> characters.  Note that "char *a" doesn't tell how big the string is.
> Declaring it "char a[2]" would work, because that would actually allocate
> two characters for the given string (including the zero terminator).
>

No.  You are incorrect.  The above example is legitimate C.  As to why it
does not work for the original poster in Think C, I don't know; it works
for me.

The string literals are allocated in the static data space by the compiler,
and the fields of the structure are assigned the addresses of those
literal strings.

Brian Donnell
NASA/JSC

+++++++++++++++++++++++++++

From: Steve Creps <[e-mail]>
Organization: Indiana University
Date: Mon, 6 Apr 1992 10:01:10 -0500

In article <[e-mail]> [e-mail] (Jerry Frain) writes:
>Can anyone tell me why the following is correct
>
>    struct foo {
>        int a;
>        int b;
>    };
>    struct foo bar[2] = {{1, 2}, {3, 4}};
>
>And yet this is not:
>
>    struct foo {
>        char *a;
>        char *b;
>    };
>    struct foo bar[2] = {{"1", "2"}, {"3", "4"}};

   I've not used Think C.  However, this is not specifically a Mac programming
problem, but rather a general C programming problem.

   In Example 1 all the memory locations get allocated because there are no
pointers used (unless you want to get technical).  Both fields in struct foo
are int, so when you declare a variable as struct foo, the memory locations
to hold both a and b are allocated.

   In Example 2, however, you are declaring the fields of foo as _pointers_,
so all that gets allocated are places to hold addresses of places to hold
characters.  Note that "char *a" doesn't tell how big the string is.
Declaring it "char a[2]" would work, because that would actually allocate
two characters for the given string (including the zero terminator).

   Note the following similar examples:

Example 3:

int foo = 1;

Example 4:

char *foo = "1";

   Both of these, however, should work.  Example 4 works not because space is
being allocated for the string, but because it is getting the address of the
space _which has already been allocated_ to store the constant string "1".

   To summarize, the problem mentioned was caused by not making sure that
space was being allocated for strings being used.  That problem is one of
the most difficult concepts to master when learning C.

- -    -    -    -    -    -    -    -    -    -
Steve Creps, Indiana University
[e-mail] (129.79.1.6)
{inuxc,rutgers,uunet!uiucdcs,pur-ee}!iuvax!silver!creps

+++++++++++++++++++++++++++

From: [e-mail] (Brian Donnell)
Date: 6 Apr 92 20:56:41 GMT
Organization: NASA/JSC

In article <[e-mail]>, Steve Creps <[e-mail]> writes:
> In article <[e-mail]> [e-mail] (Jerry Frain) writes:
> >    struct foo {
> >        char *a;
> >        char *b;
> >    };
> >    struct foo bar[2] = {{"1", "2"}, {"3", "4"}};
>
>    In Example 2, however, you are declaring the fields of foo as _pointers_,
> so all that gets allocated are places to hold addresses of places to hold
> characters.  Note that "char *a" doesn't tell how big the string is.
> Declaring it "char a[2]" would work, because that would actually allocate
> two characters for the given string (including the zero terminator).
>

No.  You are incorrect.  The above example is legitimate C.  As to why it
does not work for the original poster in Think C, I don't know; it works
for me.

The string literals are allocated in the static data space by the compiler,
and the fields of the structure are assigned the addresses of those
literal strings.

Brian Donnell
NASA/JSC

---------------------------

From: [e-mail] (Stiva F)
Subject: SADE en MPW
Date: 30 Mar 92 08:21:02 GMT


Who can help me to solve the following two problems I encountered using MPW and SADE:

- - The linker generates:
  LocalID has previous, conflicting type (error 85)
  <bad object file or compiler errors>
  The makefile looks like this:
  Asm -Sym on  file.a
  Link -Sym on  file1.a.o ... filen.a.o   -o prog
  What is the problem?

- - In SADE the following error occurs trying to set a break in a source file:
  Cannot determine break address: File "file" has corrupt symbol information
  (file is a INCLUDE file in file.a with source code in it)
  The project consists of a number of segments. The assembler source of each
  segment resides in its own folder.
  Asm places the object codes in one object folder.
  In SADE the source path variable is set to all the folders containing the
  source files.
  When I set the target on my program, every thing works fine. When I set a
  breakpoint in the first segment everything works fine.
  Setting a break in another segment produces the error.
  Stepping into a procedure belonging to another segment produces the following
  error:
  search_page_tables() bad index, ((!object_table441eba) || (....))
  Any suggestions?

  Thanks in advance.
    Fulco Stiva ([e-mail])
    Vrij Universiteit Amsterdam


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 5 Apr 92 23:24:37 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Stiva F) writes:
> - The linker generates:
>   LocalID has previous, conflicting type (error 85)
>   <bad object file or compiler errors>
>   The makefile looks like this:
>   Asm -Sym on  file.a
>   Link -Sym on  file1.a.o ... filen.a.o   -o prog
>   What is the problem?
Can't say exactly, are you using Link 3.2 and Asm 3.2, or a mix
of releases (SYM format changed between releases, so for instance if
one of the other files was compiled long time ago it maybe has old
SYM format information?

Cheers,
Kent Sandvik/DTS

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 5 Apr 92 23:24:37 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Stiva F) writes:
> - The linker generates:
>   LocalID has previous, conflicting type (error 85)
>   <bad object file or compiler errors>
>   The makefile looks like this:
>   Asm -Sym on  file.a
>   Link -Sym on  file1.a.o ... filen.a.o   -o prog
>   What is the problem?
Can't say exactly, are you using Link 3.2 and Asm 3.2, or a mix
of releases (SYM format changed between releases, so for instance if
one of the other files was compiled long time ago it maybe has old
SYM format information?

Cheers,
Kent Sandvik/DTS

---------------------------

From: [e-mail] (Mengyik Yeong)
Subject: Where are HD icons stored?
Date: Fri, 3 Apr 1992 01:40:30 GMT

I am trying to write a program to read and display some information
on volumes.  What I would like to do is to display the information
under the appropriate icon for the volume.  However I can't seem
to find where the HD icons are stored.  I have examined the system,
finder, desktop, startup device files.  Where do I have to look
to copy the ICON (?) resource?

Mengyik
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Mel Walker)
Organization: Novell, Inc. - Walnut Creek
Date: Fri, 3 Apr 1992 15:20:49 GMT

In article <[e-mail]> [e-mail] (Mengyik Yeong) writes:
>I am trying to write a program to read and display some information
>on volumes.  What I would like to do is to display the information
>under the appropriate icon for the volume.  However I can't seem
>to find where the HD icons are stored.  I have examined the system,
>finder, desktop, startup device files.  Where do I have to look
>to copy the ICON (?) resource?
>
>Mengyik
>[e-mail]
>

The "resources" for the HD icon(s) are in the HD driver code, I believe. Short
of hacking into that, you can't copy the resources, although you could
always get the picture under sys7.

+++++++++++++++++++++++++++

From: [e-mail] (Stephan Bublava)
Date: 4 Apr 92 12:24:02 GMT
Organization: Fachschaft Informatik, TU Wien

In article <[e-mail]> [e-mail] (Mengyik Yeong) wrote:

>I am trying to write a program to read and display some information
>on volumes.  What I would like to do is to display the information
>under the appropriate icon for the volume.  However I can't seem
>to find where the HD icons are stored.  I have examined the system,
>finder, desktop, startup device files.  Where do I have to look
>to copy the ICON (?) resource?

To my knowledge hard disk (as well as floppy disk) icons are stored
in the driver (nor as resource) and also drawn by the driver.

Check out: TN 272 What your Sony drives for you

Since I do not have Inside Macintosh handy, i cannot look whether this
topic is covered there, but volumes IV and/or V should have information
about this.

Hope this helps

Stephan Bublava, [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 6 Apr 92 23:27:26 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Mengyik Yeong) writes:
>
> I am trying to write a program to read and display some information
> on volumes.  What I would like to do is to display the information
> under the appropriate icon for the volume.

See IM IV-224.  It's the Disk Driver chapter which says that csCode 21 to
the driver returns an ICN#.

Of course, I've never done this, so there's probably more to it than this. ;)

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 6 Apr 92 23:27:26 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Mengyik Yeong) writes:
>
> I am trying to write a program to read and display some information
> on volumes.  What I would like to do is to display the information
> under the appropriate icon for the volume.

See IM IV-224.  It's the Disk Driver chapter which says that csCode 21 to
the driver returns an ICN#.

Of course, I've never done this, so there's probably more to it than this. ;)

Jon

---------------------------

From: [e-mail]
Subject: fortran object files
Date: 3 Apr 92 21:16:15 GMT
Organization: TULANE, BMEN, NEW ORLEANS, LA


I have Language Systems fortran object files in my Think Pascal project.
when i try to build it, i get an error"can't convert .o file". i have older
fortran files that i recompiled and added to the pascal project and
they do not cause any problems. as far as i can tell the fortran source code
is not different in the way the subroutines are called or exited.
i would really appreciate it if someone can help me with this.
i have Think pascal 2.0 and LS fortran 3.0.
Udita

+++++++++++++++++++++++++++

From: [e-mail] (Fred Walsteijn)
Date: 4 Apr 92 22:17:31 GMT
Organization: Physics Department, University of Utrecht,  The Netherlands

In <[e-mail]> [e-mail] writes:

>I have Language Systems fortran object files in my Think Pascal project.
>when i try to build it, i get an error"can't convert .o file". i have older
>fortran files that i recompiled and added to the pascal project and
>they do not cause any problems. as far as i can tell the fortran source code
>is not different in the way the subroutines are called or exited.
>i would really appreciate it if someone can help me with this.
>i have Think pascal 2.0 and LS fortran 3.0.
>Udita

The object files produced by LS Fortran 2.1 and before are not compatible
with LS Fortran 3.0.
I had to recompile some libraries after I upgraded to LS Fortran 3.0.
I have no experience with Fortran/Pascal linking (only LS Fortran and MPW C).
Hope this is relevant,
- -----------------------------------------------------------------------------
Fred Walsteijn                                | Internet: [e-mail]
Institute for Marine and Atmospheric Research | FAX:      [phone]
Utrecht University, The Netherlands           | Phone:    [phone]
- -----------------------------------------------------------------------------

---------------------------

From: [e-mail] (Andrew Derry)
Subject: How to copy resource file?
Organization: Simon Fraser University
Date: Fri, 3 Apr 1992 23:50:04 GMT

How do I copy a file that only has a resource fork?  I believe I've figgured
out how to read the resource fork and how to create a new file, then write
the resource fork to it... but then the creator and type are not the same.
Is there a way to read the creator and type of the original to use when
creating the copy?  Also, is there a way to tell when I've reached the
end of the file when reading the original?

A quick example of making an exact duplicate of a file with a 0 length
data fork and an arbitrarily long resource fork would be excellent, but
any help would be appriciated.

Also, the source file will be on a remote appleshared system.  Will this
be a problem? (will it make any difference?)

Thank you.


Andrew

+++++++++++++++++++++++++++

Organization: Sophomore, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA
Date: Sat, 4 Apr 1992 03:16:56 -0500
From: "Jeffrey T. Hutzelman" <[e-mail]>

Steps for copying a file...

1. Call HGetFInfo (GetFHInfo??) or PBGetCatInfo on the source file, to
find out stuff about it

2. Create the destination file

3. Call HSetFInfo on the destination file.  Doing things in this order lets
the destination file be in a DropBox.

4. Open both the data and resource forks of the source, or at least open
whatever you are going to use.

5. Open both forks of the destination, or whichever you are going to use.
Make sure if you are going to use both forks you OPEN both before writing
to either; this maintains the ability to store into DropBoxes.

6. You can use GetEOF and SetEOF to take care of the EOF's.  Calling SetEOF
before actually writing any of it allows the system to allocate all the
space at once, theoretically reducing fragmentation.  This becomes more
important if the desintation file is on a fileserver (including the local
machine running sharing), or in general if lots of programs will run at
once, and might write to disk.  It's also generally a good idea.

7. Read data and then write it, in large chunks (for efficiency), until you
get an error saying there is no more.

8. Close both forks of the destination file.

9. If desired, call PBSetCatInfo on the destination to set the modify date to
the same as the source.  Note that this step WILL fail if the destination was
in a dropbox; you just have to ignore it.

Sample code follows...

On second thought, I'll post the sample source once I've written it.
In the meantime, read the stuff in IM about FSRead; you'll find that
1.) It returns the error eofErr when you hit the end of the file.
2.) It returns a count of how many bytes it acutally read, as opposed to how
many you requested.

- -- Jeffrey Hutzelman

[e-mail], [e-mail], or JeffreyH11 on America Online

---------------------------

From: [e-mail] (Robert Horn)
Subject: Hard drive icons?
Organization: SUNY at Stony Brook where no one gets an education
Date: Sat, 4 Apr 1992 03:19:47 GMT

Hi!

I'm writing a program, in which I have to get the icon for any
file/folder/disk. I know how to get icons for everything except a hard drive
without a custom icon; I know that this information is in the hard drive's
driver, and that I should be able to access it through the Control() function,
something on the order of:

    csCode = 21;        /* get 'ICN#' thingy */
    theErr = Control(magicNumber, csCode, buf);
                /* should this be a call to Status by any
                   chance? */

What is the magicNumber? I've tried the drive number, the vRefNum, and a few
fairly random things. IM-IV says that this will work for a Apple 20 Meg drive,
does this work for all hard drives?

Thanks in advance for any help,
Rob

- ---
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Chris Wysocki)
Date: 4 Apr 92 04:20:20 GMT
Organization: Harvard University, Cambridge, MA

In article <[e-mail]>, [e-mail]
(Robert Horn) writes:

> I'm writing a program, in which I have to get the icon for any
> file/folder/disk. I know how to get icons for everything except a hard drive
> without a custom icon; I know that this information is in the hard drive's
> driver, and that I should be able to access it through the Control() function,
> ...

The following routine should do the trick; given a vRefNum, it returns a Handle
to the icon for the corresponding volume:

Handle GetVolumeIcon(short vRefNum)
{
    HParamBlockRec  hpb;
    ParamBlockRec   pb;
    Handle          iconH;

    hpb.volumeParam.ioNamePtr = NULL;
    hpb.volumeParam.ioVRefNum = vRefNum;
    hpb.volumeParam.ioVolIndex = 0;
    FailOSErr(PBHGetVInfoSync(&hpb));

    pb.cntrlParam.ioVRefNum = hpb.volumeParam.ioVDrvInfo;
    pb.cntrlParam.ioCRefNum = hpb.volumeParam.ioVDRefNum;
    pb.cntrlParam.csCode = 21;
    FailOSErr(PBControlSync(&pb))
    FailOSErr(PtrToHand(*(Ptr *) pb.cntrlParam.csParam, &iconH, kLargeIconSize));

    return (iconH);
}

Chris Wysocki
[e-mail]


---------------------------

From: [e-mail]
Subject: Very Early Macintosh Systre
Date: 4 Apr 92 20:48:37 GMT
Organization: Cornell University

This is not exactly a programming question, but it seemed the best forum
I could find for my question. I'm interested (for a project) on older GUIs,
in particular anything that might have been engineering prototypes for
the current Macintosh, and also anything that may have gone into the
Lisa. Also, if anyone knows anything about any other "unusual" GUIs, I
would be interested in that too.

Thanks, MJH92
(Mark Handel, [e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: 5 Apr 92 06:01:53 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


       If you've never seen an operating Lisa, and have the opportunity,
I recommend it.  The Mac, after all, is the cost-reduced version of the
Lisa, and it shows.  The Lisa has a multi-tasking protected mode
operating system, and is in some ways more advanced than the Mac.
It was just too expensive to build such a machine in 1982.

       Has anyone ever ported the Lisa environment to modern hardware?
It would be fun to see the Lisa software running on a 68040.

                    John Nagle

---------------------------

From: [e-mail] (William Ross Geck)
Subject: GWorld Woes
Date: 4 Apr 92 21:03:36 GMT
Organization: University of California at Los Angeles, EE Dept.

Hi All,

    I was wondering if somebody could tell my about the new GWorld routines.
I want to create an offscreen graphics world to which I can assign three
different PixMap's.  While doing this, I have already learned the following:

(1) The NewGWorld routine creates a pixMap of the appropriate size with
    (**pMap).baseAddr set to a Handle containing the pixMap data rather than
    the normal pointer.  (Aside: This is fine with me, I do the same for my
    own pixMaps.  I then lock and dereference the baseAddr before drawing to
    it, then do a "RestoreHandle" on it afterwards.  The LockPixels function
    does this same dereferencing when called before drawing anything to the
    port. And yes, I know that's why we should always use GetPixBaseAddr.)

(2) After calling LockPixels, I did an HGetState on the pixMapHandle, and on
    the pixMap data (now dereferenced) and found no bits set (AND no MemError).
    Yet the Swatch application informs me that these structures are indeed
    locked!

    Question:  why doesn't HGetState tell me that these handles are locked?

(3) I discovered that SetPortPix() takes as an argument a PixMapHandle rather
    than a pointer to a PixMapHandle as THINK Reference says!

(4) I did the following:
        1. pPix = GetGWorldPixMap( gPort );
        2. ePix = NewPixMap();
        3. CopyPixMap( pPix, ePix );
        4. size = GetHandleSize( (Handle)(**pPix).baseAddr );
        5. (**ePix).baseAddr = (Ptr)NewHandle( size );
    To set up a second PixMap IDENTICAL to the GWorld's.  I then called
    SetPortPix( ePix ), locked ePix and (**ePix).baseAddr, dereferenced the
    baseAddr then tried to draw into the GWorld.  BOMB!!!!  I even replaced
    step #5 with a NewPtr call (In other words, made this a normal pixMap),
    BOMB!!!

    Oh, "size" is set right, 193,920 Bytes if it matters, depth is 4.  The
    port is set to the GWorld.  There are NO memory errors (I check after every
    memory manager call).  Before the SetPortPix I can draw into pPix (the
    Original GWorld) without any problems.  I've rebuilt the project itself:
    no change.  By the way, I'm using THINK C 5.0.2 and System 7.0 with TuneUp.

Can anyone help me out?

W. Ross Geck
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Eric Berdahl)
Date: 7 Apr 92 00:42:00 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (William Ross
Geck) writes:
>
> Hi All,

Hi William!

> (1) The NewGWorld routine creates a pixMap of the appropriate size with
>     (**pMap).baseAddr set to a Handle containing the pixMap data rather than
>     the normal pointer.  (Aside: This is fine with me, I do the same for my
>     own pixMaps.  I then lock and dereference the baseAddr before drawing to
>     it, then do a "RestoreHandle" on it afterwards.  The LockPixels function
>     does this same dereferencing when called before drawing anything to the
>     port. And yes, I know that's why we should always use GetPixBaseAddr.)

Sounds reasonable that the GWorld routines do this, and it's cool that you have
found this special knowledge becuase you now understand GWorlds a little better
than the average bear (as Yogi would put it).

> (2) After calling LockPixels, I did an HGetState on the pixMapHandle, and on
>     the pixMap data (now dereferenced) and found no bits set (AND no
MemError).
>     Yet the Swatch application informs me that these structures are indeed
>     locked!
>
>     Question:  why doesn't HGetState tell me that these handles are locked?

Good question.  I don't know why this doesn't happen, but I don't think it's
anything to worry about.  I've been using GWorlds in my apps for a long time,
and they've always worked.  I think we may be trying to understand the
implementation at too fine a grain here.

> (4) I did the following:
>         [code deleted]
>     To set up a second PixMap IDENTICAL to the GWorld's.  I then called
                                ^^^^^^^^^
Apparently, it wasn't identical.

>     SetPortPix( ePix ), locked ePix and (**ePix).baseAddr, dereferenced the
>     baseAddr then tried to draw into the GWorld.  BOMB!!!!  I even replaced
>     step #5 with a NewPtr call (In other words, made this a normal pixMap),
>     BOMB!!!

To create an identical PixMap (at least, as far as you need), create another
GWorld with the same characteristics as the GWorld you want to copy (size, bit
depth, color table, device, etc).  Basically, you have to treat all the fields
of the GWorld as completely private.  You are not allowed to even look at the
values because their use is not documented except to say that they may be
different than the way the rest of the toolbox works.

Also, I try to avoid SetPortPix and NewPixMap for basically just this reason.
The only time I use PixMaps instead of GWorlds is if I need to CopyBits
somewhere given a specific digital image with a specific color table.  Then I
create a PixMap on the stack and CopyBits from it to a GWorld for more permanent
storage.

Hope this helps.
- --
Eric Berdahl
Taligent, Inc.
Internet: [e-mail]
AppleLink: BERDAHL
#include <StdDisclaimer.h>
This is a freeware signature.  What do you expect for nothing?


+++++++++++++++++++++++++++

From: [e-mail] (Eric Berdahl)
Date: 7 Apr 92 00:42:00 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (William Ross
Geck) writes:
>
> Hi All,

Hi William!

> (1) The NewGWorld routine creates a pixMap of the appropriate size with
>     (**pMap).baseAddr set to a Handle containing the pixMap data rather than
>     the normal pointer.  (Aside: This is fine with me, I do the same for my
>     own pixMaps.  I then lock and dereference the baseAddr before drawing to
>     it, then do a "RestoreHandle" on it afterwards.  The LockPixels function
>     does this same dereferencing when called before drawing anything to the
>     port. And yes, I know that's why we should always use GetPixBaseAddr.)

Sounds reasonable that the GWorld routines do this, and it's cool that you have
found this special knowledge becuase you now understand GWorlds a little better
than the average bear (as Yogi would put it).

> (2) After calling LockPixels, I did an HGetState on the pixMapHandle, and on
>     the pixMap data (now dereferenced) and found no bits set (AND no
MemError).
>     Yet the Swatch application informs me that these structures are indeed
>     locked!
>
>     Question:  why doesn't HGetState tell me that these handles are locked?

Good question.  I don't know why this doesn't happen, but I don't think it's
anything to worry about.  I've been using GWorlds in my apps for a long time,
and they've always worked.  I think we may be trying to understand the
implementation at too fine a grain here.

> (4) I did the following:
>         [code deleted]
>     To set up a second PixMap IDENTICAL to the GWorld's.  I then called
                                ^^^^^^^^^
Apparently, it wasn't identical.

>     SetPortPix( ePix ), locked ePix and (**ePix).baseAddr, dereferenced the
>     baseAddr then tried to draw into the GWorld.  BOMB!!!!  I even replaced
>     step #5 with a NewPtr call (In other words, made this a normal pixMap),
>     BOMB!!!

To create an identical PixMap (at least, as far as you need), create another
GWorld with the same characteristics as the GWorld you want to copy (size, bit
depth, color table, device, etc).  Basically, you have to treat all the fields
of the GWorld as completely private.  You are not allowed to even look at the
values because their use is not documented except to say that they may be
different than the way the rest of the toolbox works.

Also, I try to avoid SetPortPix and NewPixMap for basically just this reason.
The only time I use PixMaps instead of GWorlds is if I need to CopyBits
somewhere given a specific digital image with a specific color table.  Then I
create a PixMap on the stack and CopyBits from it to a GWorld for more permanent
storage.

Hope this helps.
- --
Eric Berdahl
Taligent, Inc.
Internet: [e-mail]
AppleLink: BERDAHL
#include <StdDisclaimer.h>
This is a freeware signature.  What do you expect for nothing?


---------------------------

From: [e-mail] (Thomas Diessel)
Subject: Looking for C++ Compiler for Mac
Date: 5 Apr 92 14:06:19 GMT
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)

I'm looking for a C++ compiler for the Mac. The only C++ compiler I've
heard of is the Zortech C++. But I would prefere a compiler that doesn't
require MPW, e.g. THINK C. So, my questions qre:
Can you recommend the Zortech C++ compiler?
Are there other C++ compilers? (especially PD, e.g. GNU g++)
Will there be a THINK C++? (I know that Symantec has bought Zortech.)

Thomas Diessel
Federal Armed Forces University, Munich
Computer Science Dept.
Werner-Heisenberg-Weg 39
W-8014 Neubiberg
Germany
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Sun, 5 Apr 92 22:17:38 EST
Organization: EnigamI, Inc., Nashua, NH


In article <diessel.702482779@gretchen> (comp.sys.mac.programmer), [e-mail] (Thomas Diessel) writes:
>I'm looking for a C++ compiler for the Mac. The only C++ compiler I've
>heard of is the Zortech C++. But I would prefere a compiler that doesn't
>require MPW, e.g. THINK C. So, my questions qre:
>Can you recommend the Zortech C++ compiler?
>Are there other C++ compilers? (especially PD, e.g. GNU g++)
>Will there be a THINK C++? (I know that Symantec has bought Zortech.)

I just asked a question on the Zortech product.  Unfortunately, the
answer came back rather negative.  Maybe in a couple of years.

The only other C++ that is available on the Mac is MPW C++.  Think
has not yet produced a C++ compiler.  The best they have is an implimentation
of Apple's minimal object C.

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

---------------------------

From: [e-mail] (Thomas Burglin)
Subject: Macintosh C Programming primer examples (Q) Where?
Date: 6 Apr 92 06:31:00 GMT
Organization: Molecular Biology, Massachusetts General Hospital, Boston

Hi, I was wondering if any ftp site out there has at least some
of the example programs from the two books:
Macintosh C Programming Primer vol I & vol II.
Maybe not, since that might be an infringment on the copyright (I
didn't read the small print in the book).
But if anybody knows of some source for the example codes,
I would appreciate the tip. (No, I don't want to pay megabucks
for the disk as advertised in the back of the book)
Thanks
Thomas Burglin
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail]
Date: 7 Apr 92 14:49:17 GMT
Organization: BC Systems Corporation

In article <[e-mail]>, [e-mail] (Thomas Burglin) writes:
> Hi, I was wondering if any ftp site out there has at least some
> of the example programs from the two books:
> Macintosh C Programming Primer vol I & vol II.
> Maybe not, since that might be an infringment on the copyright (I
> didn't read the small print in the book).
> But if anybody knows of some source for the example codes,
> I would appreciate the tip. (No, I don't want to pay megabucks
> for the disk as advertised in the back of the book)
> Thanks
> Thomas Burglin
> [e-mail]

I have most of the programs finished in Vol. 1 but I haven't started on Vol. 2
yet as I only have a Mac Plus (soon to be an LC II when my Tax return arrives)
so I can e-mail them to all who are interested.  Please send me e-mail directly
as I can't always read the news.

If anyone has a problem with this please let me know, otherwise I'm willing to
send them out.  I should be able to send them next week some time (April 13 or
so) as it will give me time to finish the last 4 programs in Vol. 1.



- --
[e-mail]
Victoria, British Columbia, Canada

---------------------------

From: [e-mail] (Michael Harpe)
Subject: Problem with THINK C 5.0.2 (long)
Date: 6 Apr 92 15:09:17 GMT
Organization: University of Louisville

I have two questions regarding a problem i'm seeing with THINK C 5.0.2.  I
am working on a program that reads in microprocessor cross assembler output
and does some processing with the decoded data.  For checksum calculations,
it's necessary to perform some math on a variable declared thus:

unsigned char rbyte;    /* should be an eight bit byte, true? */

and I want to read this byte from a buffer containing ASCII representations of
hex bytes: AAF3D345...  I should be able to do an sscanf:

    itemCount = sscanf(ptr,"%2X",&rbyte);    /* get a byte */

This should give me one of the bytes in rbyte, correct?  Well, the only way
I can get the behavior I expect is to change the unsigned char declaration
to an unsigned int.  Adding the byte I read to an unsigned char works
correctly.  The problem is that sscanf is insisting on storing what it finds
in TWO bytes, not just one.  If it reads 0x23, it stores that as 0023 in two
locations.  I discovered this with the debugger.  Changing the field descriptor
to "%X" gives the same result.

That seems incorrect to me.  Taking this at face value, there appears to be
no way to interpret two ASCII characters to an unsigned char.  This works on
UNIX, that's where originally wrote the routine.  I have turned off the
THINK extensions and set up ANSI compliance.

OK, I found a workaround so what's the big deal?  Wellll, after I start this
processing loop, I want to display a dialog box that shows the progress I am
making through the file.  Given:

unsigned short objAddr = 0xE000;
unsigned short bytecnt = 35;
char strobjAddr = "\0";
char strbytecnt = "\0";

I should be able to:

itemCount = sprintf(strobjAddr,"%.4X",objAddr);
itemCount = sprintf(strbytecnt,"%.2u",bytecnt);

and end up with strobjAddr = "E000\0" and strbytecnt = "35\0".  NOT!  I had to
change the sprintf to read:

itemcount = sprintf(strobjAddr,"%.4lX",objaddr);
itemcount = sprintf(strbytecnt,"%.2lX",bytecnt);

Note that I had to make them BOTH read as longs before this worked.  I got
zeroes back with the first method.

Is this a compiler problem?  Or do I need more time with my C textbook (the
latter being more likely).  The only reason I suspect this is that is seems
to contradict the typing rules.  Those are short integers so it seems kinda
silly to have to read them as longs.

Please respond directly to me.  If this is a really basic and silly mistake
I apologize in advance.  I would appreciate it if you would tell me so
in a constructive way, though :-).

Mike Harpe
University of Louisville

+++++++++++++++++++++++++++

From: [e-mail] (John Pfeifer)
Date: 6 Apr 92 19:38:39 GMT
Organization: National Inst. of Health, DCRT, CSL

Michael Harpe says:

> unsigned char rbyte;    /* should be an eight bit byte, true? */

Doesn't hafta be.

> and I want to read this byte from a buffer containing ASCII representations of
> hex bytes: AAF3D345...  I should be able to do an sscanf:
>
>    itemCount = sscanf(ptr,"%2X",&rbyte);    /* get a byte */

> This should give me one of the bytes in rbyte, correct?

Nope.  Read your manual (K&R p246 or THINK C: Standard Libraries Reference p60).  '%X'
returns you an int.  Same thing for printf.

- -John
- --
#include <stdsig.h>

        John Pfeifer                    internet: [e-mail]

    "The most creative and holy of men are always quite mad.
     It is simply a social thing as to wether one is sane or
     _insane_."                -The Madonna Vampira

+++++++++++++++++++++++++++

From: [e-mail] (Michael Harpe)
Date: 7 Apr 92 13:36:28 GMT
Organization: University of Louisville

Thanks to all who responded to this.  I just misunderstood the %X designator.
I had correctly deduced what was happening, I just didn't understand why it
was happening.  This cleared it up.  I cleaned up the code last night.

Source level debuggers are WONDERFUL learning tools.  It really helps to be
able to watch what happens and single-step through the program.

Actually, programming the Mac isn't as bad as I thought it would be.  The
books "Macintosh Programming Primer" are invaluable.  I would really be stuck
without them.  The net helps alot too :-).  I've been lurking on this group
for some time and picked up a lot of tips here as well.

Thanks again.

Mike

---------------------------

End of C.S.M.P. Digest
**********************